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es systemes d'exploitation de Microsoft regorgent d'interfaces de programmation 
diverses et variees. Parmi elles, DPAPI, qui permet de chiffrer et dechiffrer les 
donnees jugees sensibles de fagon transparente, est restee pendant plus de 
10 ans non documentee. Nous vous proposons dans cet article de regarder sous le 
capot et de decouvrir les secrets du moteur de chiffrement de Windows. 




1 Data Protection API 



Derriere ce nom barbare se cache une interface de 
programmation qui a ete introduite par Microsoft dans 
ses systemes d'exploitation a partir de Windows 2000. 
Elle est destinee a encapsuler de maniere transparente les 
donnees sensibles du systeme et des applications dans des 
structures opaques qui sont chiffrees et protegees contre 
toute alteration, frauduleuse ou non. Notons que si le role 
de DPAPI est bel et bien de proteger des donnees, tout en 
enlevant aux developpeurs d'applications la douloureuse 
epine de la gestion des cles de chiffrement, le stockage 
de la structure renvoyee reste de la responsabilite des 
applications tierces. De ce fait, des BLOB DPAPI peuvent 
etre retrouves un peu partout sur un disque dur ou un 
stockage externe. 

Parmi les donnees sensibles protegees par DPAPI, 
nous pouvons citer : 

- les cles Wi-Fi memorisees par Windows ; 

- les identifiants de connexion a Google Talk, Skype 
ou encore MSN Messenger ; 

- les entrees de formulaires de Google Chrome ; 

- les comptes Microsoft Exchange, 

- les cles privees associees aux certificats , notamment 
ceux utilises pour le chiffrement des fichiers via 
Microsoft EFS [I]. 

Si le principe de base de DPAPI est de lier les donnees 
a chiffrer au compte utilisateur Windows arm de garantir 
(theoriquement) que les donnees protegees ne puissent 
etre derobees par un autre utilisateur du systeme, notons 
que Windows utilise egalement DPAPI pour proteger des 
donnees a l'echelle de la machine. Dans ce cas, c'est au 
compte SYSTEM que les donnees sont rattachees. Sans 
surprise, c'est le processus LSASS [2], grand maitre 



des cles dans le monde de Windows, qui s'occupe du 
chiffrement et du dechiffrement des donnees DPAPI. Si 
tout parait clair en surface, nous verrons plus tard que 
certains choix de Microsoft concernant l'implementation 
de DPAPI recelent bien des surprises. 

Pour accomplir sa mission, DPAPI expose deux fonctions 
completement symetriques au travers de la bibliotheque 
crypt32.dll : 

CryptUnprotectData ( 
DATAJLOB *pDataIn, 
LPCWSTR szDataDescr, 
DATAJLOB *pOptional Entropy, 
PVOID pvReserved, 
CRYPTPROTECTJROMPTSTRUCT *pPromptStruct , 
DWORD dwFlags, 
DATAJLOB *pDataOut) 

CryptProtectDataC 
DATAJLOB *pDataIn, 
LPCWSTR szDataDescr, 
DATAJLOB *pOptional Entropy, 
PVOID pvReserved, 
CRYPTPROTECTJROMPTSTRUCT *pPromptStruct, 
DWORD dwFlags, 
DATAJLOB *pDataOut) 

Le champ pOptionalEnt ropy correspond a un secret 
partage que les developpeurs souhaitant utiliser DPAPI 
peuvent ajouter. La documentation de Microsoft stipule 
que cela permet d'eviter qu'une autre application ne 
parvienne a dechiffrer vos donnees. 

Le parametre pPromptStruct permet de passer un 
composant d'interface graphique qui sera automatiquement 
affiche a l'utilisateur pour lui demander un mot de passe 
complementaire. En pratique, cette fonctionnalite n'est 
pour ainsi dire jamais utilisee. II y aurait en effet tres 
peu d'interet a proteger un mot de passe d'un utilisateur 
en lui demandant un enieme sesame. 
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2 Les structures DPAPI 



Une petite recherche dans le code source du projet 
Wine [3] permet deja d'obtenir quelques pistes pour 
mieux comprendre les structures utilisees par DPAPI. 
Malheureusement, l'implementation realisee dans le 
cadre de ce projet est incomplete, les developpeurs ayant 
visiblement stoppe leur analyse avant d'etre completement 
interoperable avec Windows au niveau cryptographie. A ce 
propos, il est interessant de signaler qu'un des obstacles 
majeurs a l'utilisation de EFS sous Linux provenait de 
l'absence de documentation du fonctionnement interne de 
DPAPI. Cet obstacle etant maintenant surmonte, esperons 
que cette compatibilite ne saurait plus tarder. Pour en 
revenir a 1'analyse effectuee par l'equipe de Wine, notons 
qu'une bonne partie de leur analyse s'est averee valide 
et bien utile comme point de depart. 



.e DATA BLOB 



La premiere structure de donnees a laquelle nous 
sommes confronted est le DATA_BL0B qui est renvoye par 
l'API de Microsoft. II correspond a une structure serialisee 
pouvant etre definie par la pseudo-structure C suivante : 



struct 
DWORC 
GUID 
DWORC 
GUID 



BYTE 
ALG I 



BYTE 

DWORD 

ALGJ 



BYTE 
DWORI 
BYTE 



BYTE 

} ; 



wincryptjatablob { 
dwVersion, 
pbProvi der , 
cbHasterkeys, 

pbHasterkeys[cbMasterkeys] , 

dwFlags, 

cbDescription, 

pbDescn'ptionicbDescn'ption], 
D algCipher, 
cbKey , 
cbData, 

pbData [cbData] , 
dwUnknown, 
D algHash, 
dwHashSize, 
cbSalt, 

pbSalt[cbSalt], 
cbCipher, 

pbCipher[cbCipher], 
cbCrc, 

pbCrc[cbCrc] 



Le champ pbProvider indique quel est le fournisseur 
de primitives cryptographiques qui a servi a generer cette 
structure. En pratique, il n'y a qu'un seul fournisseur 
utilise, celui fourni par defaut par Microsoft, dont le 
GUID [4] est df9d8cd0-l50l-lldl-8c7a-0c04fc297eb. 

La liste des fournisseurs cryptographiques compatibles 
avec DPAPI peut etre obtenue via la base de registres 
en enumerant les cles contenues sous HKLM\Sof tware\ 
Microsof t:\Cryptography\Protect\Providers. 

Le tableau suivant, pbMasterkeys, est a peu pres 
similaire au precedent : il contient la liste des cles ayant 
servi a proteger les donnees. La encore, en pratique, nous 
n'avons jamais rencontre de structure presentant plus 
d'une Masterkey. Ces cles, contenant 512 bits d'alea, sont 
generees et renouvelees automatiquement par le systeme 



tous les 3 mois. Cette valeur est immuable puisqu'elle est 
ecrite directement dans le code de la DLL lsasrv.dll. 

La description qui a pu etre fournie au moment du 
chiffrement des donnees est recopiee directement dans 
la structure, dans le champ pbDescription. Attention 
cependant, bien que la chaine soit encodee en UTF-16LE, 
la faille indiquee est bel et bien en octets ! 

Nous retrouvons egalement dans cette structure deux 
identifiants qui specifient les algorithmes employes pour 
effectuer le scellement des donnees. Lidentifiant algCipher 
[5] est utilise pour connaitre l'algorithme de chiffrement 
(3DES par defaut jusqu'a Vista et AES-256 pour Seven), 
l'identifiant algHash, quant a lui, indique la fonction de 
hachage utilisee pour le HMAC [6]. Les identifiants que 
nous trouvons dans les fichiers mentionnent l'utilisation 
de HMAC (0x8009, SHA1 etant force dans le code) jusqu'a 
Vista, puis SHA512 (0x800e) pour Seven. Ces valeurs 
peuvent toutefois etre surchargees par un administrateur 
au travers de la base de registre. D'ailleurs, 1'analyse de la 
DLL Isas rv . dll nous revele quelques cles, toutes de type 
DWORD, pas toujours documentees, permettant d'influencer 
le comportement de DPAPI, situees sous HKLM\Sof tware\ 
Microsoft\Cryptography\Protect\Providers\ [GUID] : 

- HasterKeylterationCount : nombre d'iterations 
de l'algorithme de hachage dans la fonction de 
derivation ; cette valeur ne pourra neanmoins pas 
descendre en dessous d'un certain seuil, mis en dur 
dans le code, pour ne pas affaiblir la securite [7]. 

- MasterKeyLegacyCompliance : active le mode de 
compatibilite Windows 2000. 

- MasterKeyLegacyNt4Domain : modifie le comportement 
du recouvrement de cle ; plus de details sur [8]. 

- DistributeBackupKey : role indetermine. 

- ProtectionPolicy : impact precis inconnu ; serf 
a conserver la validite d'une Masterkey apres un 
changement de mot de passe [9]. 

- Recovery Version : version de la structure de 
donnees de la cle de recouvrement. 

- Encr Alg : algorithme de chiffrement, ce dernier 
doit avoir une implementation dans le Cryptographic 
Service Provider par defaut. 

- Encr Alg Key Size : taille de la cle a generer pour 
le chiffrement choisi. 

- MAC Alg : fonction de hachage utilisee pour le HMAC. 

- MAC Alg Key Size : role encore indetermine ; 
l'hypothese la plus probable serait la longueur de 
l'alea servant de cle a l'algorithme HMAC qui, par 
defaut, est de 16 octets. 

Le tableau d'octets pbData serf au calcul de la cle de 
dechiffrement, tandis que le tableau pbCipher contient 
les donnees protegees par DPAPI. 



2.2 La Masterkey 



L'ensemble des cles est enregistre dans le dossier 
i>APPDATA%\Microsoft\Protect\ [USER-SID] pour 
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WCHAR 



chaque utilisateur, ainsi que dans le dossier %SystemRoot%\ 
System32\Microsoft\Protect pourle compte SYSTEM. A 
chaque fois, le fichier « Preferred » contient une reference 
a la Masterkey courante ainsi que sa date d'echeance. 

Chaque fichier de Masterkey est nomme d'apres 
son identifiant unique et est compose d'un en-tete 
correspondant a la pseudo-structure C : 

struct wincrypt_masterkey_header { 
dwRevision, 
dwUnknownl, 
dwUnknown2, 
wcsKeyGUID[36] , 
dwUnknown3, 
dwUnknown4, 
dwFlags, 
cbMasterkey, 
cbBackupKey , 
cbCredh i stEntry , 
cbDomai nKey 

}; 

Notons que l'identifiant unique de la cle est repris 
sous forme de chaine de caracteres encodee en UTF- 
16LE directement dans l'en-tete. 

Les quatre derniers champs indiquent la taille, en 
octets, des structures qui peuvent suivre cet en-tete. Le 
premier bloc correspond a la Masterkey chiffree. C'est 
celui-ci qui nous est utile pour dechiffrer un DATA_BL0B. 

Le second bloc semble etre une cle de secours dont 
1'utilite nous est encore inconnue a ce jour. 

Ces deux structures sont tres semblables et peuvent 
etre representees par la pseudo-structure C suivante : 

struct wincryptjnasterkeyjnasterkeybloc { 
dwRevision, 
pbSalt[16], 
dwRounds, 
algMAC, 
algCipher, 
pbEncrypted[] 
}; 



BYTE 



ALGJD 
ALGJD 
BYTE 



Les champs contenus dans cette structure parlent 
d'eux-memes, a part dwRounds, qui indique le nombre 
d'iterations a effectuer lors de l'utilisation de la fonction 
PBKDF2 [10]. 

Le bloc suivant pointe vers une entree dans le fichier 
CREDHIST sur lequel nous reviendrons plus tard, et qui 
n'est utilise que dans le cadre d'un ordinateur ne faisant 
pas partie d'un domaine Active Directory. 

Sa structure est extremement simple : 

struct wincrypt_masterkey_credhistentry { 
DWORD dwRevision, 
BYTE pbCredhistGUID[] 

}; 

Le dernier bloc, enfin, n'est present que si la machine est 
inscrite dans un domaine Active Directory. II correspond a 
une structure reqroupant a la fois un secret chiffre (la cle 
publique sur controleur de domaine) et un bloc de donnees 
permettant de verifier les autorisations d'acceder aux 
donnees. Le tout s'effectue au travers de RPC securises. 
Le lecteur interesse pourra se reporter a la documentation 
officielle des structures ainsi que des echanges [II]. 



2.3 Le fichier CREDHIST 



Nous avons vu au paragraphe precedent qu'un fichier 
de Masterkey pouvait contenir un lien vers une entree du 
fichier CREDHIST. Le role de ce fichier est sans conteste la 
plus grosse surprise que nous ayons rencontree lors de notre 
analyse de DPAPI. Ce fichier contient l'historique des mots 
de passe de l'utilisateur depuis la creation du compte ! Bien 
entendu, ces derniers ne sont pas conserves en clair, mais 
sous forme de liste d'empreintes SHA-1 qui sont utilisees 
pour dechiffrer les anciens fichiers Masterkey. 

Ce choix, aussi etrange qu'il puisse paraitre, a une 
justification toute simple : les performances ! Sans le 
fichier CREDHIST, a chaque changement de mot de passe, 
le systeme serait contraint de dechiffrer l'ensemble des 
fichiers Masterkey pour les proteger a l'aide du nouveau 
mot de passe. A raison d'une nouvelle cle tous les 3 mois, 
chacune necessitant plusieurs milliers d'iterations de 
SHA-1 pour la fonction PBKDF2, nous vous laissons le soin 
de calculer a quel point votre ordinateur serait ralenti au 
bout de seulement une annee d'utilisation. 

Pour resoudre ce probleme, Microsoft a decide de ne rechiffrer 
que la Masterkey courante et de conserver un historique des 
precedentes empreintes de mot de passe afm d'etre apte a 
lire les BLOB chiffres avec une ancienne Masterkey. Ainsi, 
lorsqu'une Masterkey plus ancienne estsollicitee, cette derniere 
sera dechiffree avec l'ancienne empreinte recuperee dans le 
fichier CREDHIST et sera rechiffree avec l'empreinte du mot 
de passe actuel, ce qui facilitera son utilisation ulterieure. 

Toute cette complexity est due au fait que DPAPI n'agit 
pas comme un portefeuille de donnees sensibles. N'etantpas 
responsable du stockage des donnees, il lui est impossible 
de savoir a tout instant si une Masterkey est toujours 
utilisee ou non. 

Le format du fichier CREDHIST est aussi un petit peu 
deroutant, puisqu'il doit etre lu a l'envers. 

Quand un utilisateur decide de changer de mot de passe, 
Windows utilise l'empreinte SHA-1 du nouveau mot de passe 
comme cle de chiffrement pour proteger l'empreinte SHA-1 
de l'ancien mot de passe. Le bloc chiffre ainsi obtenu est 
ensuite ecrit a la fin du fichier CREDHIST, creant une liste 
chainee d'empreintes SHA-1 chiffrees. 



Structure 
pass 



Structure 
pass 2 



Structure 
pass 



Structure 
pass 



cure * 

) 

ture t 



Structure 
pass n-1 



ture / 



SMAhpmword) 



Fig. 1 : Schema de la structure d'un fichier CREDHIST 
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Chaque entree du fichier est representee par le 
pseudo-code C suivant : 

struct wincrypt_credhist_entry { 



DWORD 


dwRevision, 


ALG ID 


algHash, 


DWORD 


dwRounds, 


DWORD 


dwUnknownl, 


ALG ID 


algCipher, 


DWORD 


cbData, 


DWORD 


cbHash, 


BYTE 


pbSalt[16], 


RPC SID 


userSID, 


BYTE 


pbEncrypted[], 


DWORD 


dwRevi si on2 , 


BYTE 


pbCredhistGUID[16], 


DWORD 


dwEntrySize 



} ; 

Notons le champ final dwEntrySize, qui indique la 
taille de la structure et sans lequel il serait totalement 
impossible de relire le fichier. 

Une fois toutes les entrees lues, il reste la structure 
suivante, qui contient I'identifiant unique du mot de 
passe actuel : 

struct wincrypt_credhist_footer { 
DWORD dwRevision, 
BYTE pbCurrentPasswordGUID[16], 
DWORD dwNull 

}; 



3 Dechiffrons a present ! 



Lors de l'utilisation classique du systeme, toutes les etapes 
de decMffrement sont transparentes. Windows s'occupe tout 
seul d'aller chercher les donnees la oil elles se trouvent, 
quant a 1'empreinte SHA-1 du mot de passe de l'utilisateur, 
elle est tout simplement calculee en parallele de la phase 
d'authentification : le mot de passe saisi est conserve sous 
forme d'empreinte SHA-1 dans la memoire de LSASS. 

Les cles correspondant au compte SYSTEM sont quant 
a elle protegees par une empreinte SHA-1 situee dans le 
« LSA Protected Storage », sous le jeton DPAPI_SYSTEM . 
La structure contenue contient un numero de version de 
structure suivi de deux empreintes SHA-1 : la premiere 
permet de deproteger les cles situees directement dans le 
sous-repertoire S-l-5-18, la seconde empreinte deprotege 
les autres jeux de cles (S-l-5-18\User et S-l-5-20). 

Mais dans le cadre d'un pentest ou d'une analyse 
forensique, il peut etre tres interessant d'avoir acces 
a ces donnees de maniere « offline ». Ne serait-ce que 
le fichier CREDHIST, qui constitue a lui seul une mine 
d'informations precieuses pour comprendre la logique 
du changement de mot de passe des utilisateurs. 



ATTENTION 

Les algorithmes qui sont decrits ici concernent 
Windows XP et Windows Vista. Les changements 
operes dans Windows Seven n'ont pas fini d'etre 
analyses a l'heure de la redaction de cet article. 



3.1 Le fichier CREDHIST 



Pour reussir a lire les empreintes contenues dans ce 
fichier, il faut I'identifiant de securite de l'utilisateur, son 
SID, ainsi que son mot de passe (ou a defaut son empreinte 
SHA-1 une fois le mot de passe encode en UTF-16LE). 

Chaque entree peut etre alors dechiffree a l'aide du 
code Python suivant : 

import hashlib, hmac, struct 
from M2Crypto import * 

def pbkdf 2 ( passphrase , salt, keylen, iterations) : 
buff = "" 
i = 0 

while len(buff) < keylen : 
i += 1 

init = hmac.newlpassphrase, salt + struct. pack( " ! L" , i), hashlib. shall. digest!) 
tup = init 

for j in ranged, iterations) : 

tup = hmac.newfpassphrase, init, hmac. shall. digest!) 

init = "".join([chr(ord(x) ' ord(y)) for (x,y) in ziptinit, tup)]) 
buff += init 
return buf f [ : keylen] 

def decryptCredhistfrawData, passwordHash, userSID, credhi stl V , rounds) : 
cipherkeyLength = 192 ## 3DES 
cipherlVLength = 64 ## 3DES 
cbData = 20 ## contenu dans la structure Credhi st 
encKey = hmac.newtpasswordHash, userSID, hashlib. shall. digest!) 
tup = pbkdf2 ( encKey , credhi stIV , cipherkeyLength + cipherlVLength, rounds) 
cipher = EVP.Cipher("des_ede3_cbc", tmp[ :cipherKeyLength] , 
tmp[ci pherKeyLength : ] , 
m2, decrypt, 0) 
cipher. set_padding(0) 
cleartext = cipher. update! rawData ) 
cipher. final!) 
return cleartext[:cbData] 

Nous voici done, a Tissue de cette etape, armes 
d'un dictionnaire permettant d'obtenir instantanement 
1'empreinte SHA-1 d'un mot de passe a partir de son GUID. 



3.2 La Masterkey 



Nous ne nous interesserons ici qu'au bloc de donnees 
qui contient la Masterkey ; comme stipule precedemment, 
nous n'avons pas termine d'etudier l'utilite et la structure 
des autres blocs contenus dans ce fichier. 

Le bloc de Masterkey est protege exactement de la 
meme fagon que les entrees du fichier CREDHIST. 

Les fonctions vues precedemment peuvent done etre 
reutilisees, il suffira de remplacer le parametre credhistIV 
par le champ pbSalt contenu dans la Masterkey, et au 
lieu de retourner les 20 premiers octets dechiffres, il 
faudra cette fois-ci recuperer les 64 derniers octets. 

La Masterkey est ainsi deprotegee et nous pouvons 
passer a la derniere structure. 



3.3 Le DATA BLOB 



Pour dechiffrer un DATA_BL0B, il nous faudra recuperer 
sa Masterkey ainsi que l'entropie optionnelle qui a pu etre 
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fournie au moment de la protection des donnees. Le cas 
du mot de passe fort ne sera pas traite dans ces lignes. 
Ce dernier cas, tres rarement utilise, permet d'afncher 
une interface graphique demandant a l'utilisateur de 
saisir un mot de passe. Deux niveaux de securite existent, 
Medium et High. Ce mecanisme etant rarement mis en 
ceuvre, il n'a pas ete etudie davantage. 

Etrangement, la Masterkey precedemment obtenue 
ne servira pas telle quelle. C'est son empreinte SHA-1 
qui sera utilisee afin de calculer les cles de chiffrement 
3DES. Jusqu'alors, les algorithmes utilises par Microsoft 
nous ont permis de generer a la fois les 3 cles DES, mais 
egalement le vecteur d'initialisation pour le chiffrement 
CBC. Ici, nous avons a nouveau une autre surprise, car 
le vecteur d'initialisation sera nul ! 

Voici le code Python permettant de dechiffrer un 
DATA_BL0B : 

import hashlib, array 
from M2Crypto import * 

def bitcountj(x) : 

x = ((x&0xaa)»l) + (x&0x55) 
x = ((x&0xcc)»2) + (x&0x33) 
x = C(x&0xf0)»4) + (x&0x0f) 
return x 

def CryptDeri veKey ( h ) : 

h = hashlib. shal(h).digest() 
h += "\x00" * 64 

i pad = "".join(chr(ord(x) " 0x36) for i in range(64)) 
opad = "".join(chr(ord(x) * 0x5c) for i in range(64)) 
tmp = array. array ( "B" ) 

trrp . f romstr i ng( hashl i b . shal ( i pad). digest!) + hashlib. shal(opad). digest!)) 
for (i , v) in enumerate(tmp) : 

tmp[i] *= (bitcount_B(v)"l)&l 
return tmp.tostringO 

def decryptDatablobtpbCipher, pbOata, masterkey, entropy= "") : 
cipherkeyLength = 192 ## 3DES 
cipherlVLength = 64 ## 3DES 

masterkey = hashlib. shal(masterkey).digest() + "\x00" * 64 

i pad = "".join(chr(ord(x) " 0x36) for i in range(64)) 

opad = "".join(chr(ord(x) " 0x5c) for i in range(64)) 

tmp = hashlib. shaKipad + pbData).digest() 

keys = CryptDeri veKey(hashl ib.shaKopad + tmp + entropy). digest!)) 

cipher = EVP.Cipher("des_ede3_cbc", keys[:cipherkeyLength], 

"\x00" * cipherlVLength, m2. decrypt, 0) 
cipher. set_padding(0) 
cleartext = cipher. update(pbCipher) 
cipher. finalO 
return cleartext 



4.1 Cles Wi-Fi 



Microsoft Windows fournit de base un mecanisme 
permettant de gerer les reseaux Wi-Fi auxquels les 
utilisateurs se connectent [12]. Meme si ce mecanisme 
est tres souvent remplace par un logiciel fourni par 
le constructeur de la carte Wi-Fi, il n'en demeure pas 
moins utilise. 

Les informations de chaque borne sans fil sur laquelle 
l'utilisateur s'est connecte sont memorisees et fourmillent 
de details aussi precis que l'heure de dernier contact 
avec une precision de 100ns ! 

Tout peut etre retrouve dans la base de registre, en ce 
qui concerne Windows XP, sous la forme d'une structure 
opaque, sous la cle HKLM\SOFTWARE\Mic rosof t\WZCSVC\ 
Pa rameter s\Interf aces\ [ inter f aceGUID ] \Static#0000, 
tandis que sous Windows Vista et suivants, il faudra se 
tourner vers un fichier XML qui sera de suite beaucoup plus 
lisible : C:\ProgramData\Microsoft\Wlansvc\Profiles\ 
Interf aces\ [Interf aceGUID] MProfileGUID] .xml. 

Nous laissons le soin au lecteur de s'interesser aux 
differents champs contenus pour ne pas depasser le 
cadre de cet article. 

Les cles permettant de se connecter a la borne 
concernee sont protegees au moyen de DPAPI, a l'aide 
du compte SYSTEM, Microsoft ayant visiblement considere 
qu'il n'etait pas opportun de cloisonner ces informations 
entre les utilisateurs. 

Neanmoins, une fois les donnees dechiffrees, nous 
n'obtenons toujours pas la cle partagee permettant de 
s'accrocher au reseau. En effet, Microsoft a decide de 
ne pas laisser la cle telle quelle et a ajoute une phase 
de masquage au moyen d'un simple XOR. 

C'est done cette cle qui peut etre retrouvee dans la 
DLL wzcsvc . dll sous le symbole gchFakeKeyMaterial, 

qui vous sera utile pour arriver a vos fins : 

xorkey = [ 0x56, 0x66, 0x09, 0x42, 0x08, 0x03, 0x98, 0x01, 0x4D, 
0x67, 0x08, 0x66, 0x11 ] 



loitation des mots de 
passe 



4 Exemples 



En debut de cet article, nous evoquions quelques 
applications qui se reposent sur DPAPI pour proteger 
leurs donnees, principalement des couples d'identifiant/ 
mot de passe. Certes, pour recuperer les identifiants, 
il faut etre a meme de passer la couche de chiffrement 
DPAPI, mais encore faut-il savoir ou ces donnees sont 
conservees et, le cas echeant, l'entropie optionnelle ainsi 
que les traitements supplementaires a accomplir. C'est 
precisement l'objet de ce chapitre. 



Comme indique precedemment, Sexploitation d'un 
fichier CREDHIST dans le cadre d'un pentest peut s'averer 
tres utile. 

En partant de ce fichier, il nous est possible, sans 
pour autant les connaitre, de savoir combien de fois 
un utilisateur a change de mot de passe depuis qu'il a 
son compte. 

Une fois les empreintes dechiffrees, il est egalement 
possible de tenter de les casser au moyen d'un outil et 
d'un bon dictionnaire. Attention toutefois a l'encodage, 
car DPAPI est tres friand d'Unicode. C'est done bien le 
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mot de passe encode en UTF-16LE qu'il faudra casser, ce 
que ne savent pas faire nativement les outils classiques 
comme John The Ripper [13]. 

Enfin, l'empreinte SHA-1 du mot de passe courant 
de l'utilisateur est conservee dans l'espace memoire 
de LSASS. En mettant un ordinateur en hibernation, il 
est possible de lui dire de se reveiller avec la session 
deja deverrouillee, ce qui implique que cette empreinte 
doit, selon toute vraisemblance, etre sauveqardee dans 
le fichier hiberfil . sys. Neanmoins, cette valeur a peu 
de chance d'apparaitre en clair et sera plutot protegee 
par la fonction LsaProtectMemory ( ) [14]. 



peut-etre a tort, BackupKey dans cet article) ? Est-ce 
une cle de compatibility ? Pourquoi sous Windows XP 
et Vista le nombre d'iterations dans la fonction PBKDF2 
est-il positionne a 1 sur cette cle tandis que Windows 
7 le positionne a la meme valeur que la cle principale ? 

Le lecteur interesse par le sujet pourra toujours se 
rendre sur notre site internet sur lequel nous avons 
mis a disposition des outils permettant de manipuler 
les structures DPAPI comme DPAPIck [15]. Ce dernier 
est en train de subir une refonte complete afin de nous 
permettre d'y ajouter plus rapidement nos dernieres 
avancees autour de cette couche de chiffrement. ■ 



4.3 Chiffrement de fichiers par 
EFS 



II ne sera pas tres difficile d'accepter que sur un 
disque dur, un fichier chiffre est synonyme d'un fichier 
interessant. Windows fournit nativement un mecanisme 
permettant de chiffrer des fichiers, accessible directement 
depuis rinterface graphique, appele EFS pour Encrypted 
File System. 

L'utilisation d'EFS repose sur un certificat et sa cle 
privee. II suffira done, pour acceder de fagon transparente 
aux fichiers chiffres par EFS, de s'approprier le certificat 
et la cle privee de l'utilisateur vise. Le certificat etant 
par definition de nature publique, il ne posera guere de 
soucis. Quant a la cle privee, elle est tout simplement 
protegee au moyen de DPAPI ! 

Vous trouverez les fichiers concernes dans le dossier 
%APPDATA%\Microsoft\Crypto\RSA\ [SID]. 

Les primitives de programmation offertes par Windows 
permettent tres simplement d'importer un certificat de 
chiffrement EFS et sa cle privee une fois cette derniere 
deprotegee. 



Conclusion 



Nous avons leve le voile sur les principales structures 
intervenant dans le contexte de DPAPI, mais il reste des 
champs, voire meme des blocs de donnees entiers, qui 
restent neanmoins inconnus. 

Les changements apportes dans le cadre de Windows 
7 meritent eux aussi d'etre analyses, tout comme le 
fonctionnement de DPAPI dans un domaine Active 
Directory. Par exemple, le fichier CREDHIST ne semble 
pas etre exploite lorsque la machine est enregistree 
dans un domaine. Le controleur de domaine possede-t- 
il des donnees protegees par DPAPI dans sa base Jet ? 
Le fichier « Credential Store » contenant notamment 
les mots de passe des partages reseau ainsi que les 
identifiants de compte Exchanqe ressemble fortement 
a un bloc chiffre DPAPI, mais avec quelques drapeaux 
particuliers. A quoi peut bien servir ce qui ressemble 
a une seconde cle dans le fichier MasterKey (appelee, 
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